Computers, particularly server units, may have several active software sub-systems in memory at one time. These software sub-systems are managed using what is commonly called a software load image. The software load image describes the software sub-systems in the software load of a computer.
Difficulties are frequently encountered when managing these software loads. The first problem occurs because of the way in which software loads are created and packaged. Commonly, when a software load is created, many sub-systems are included which are not required in all configurations and hence are considered to be optional. The second problem occurs because the software load of a computer is often dynamic in nature. For example, during the operating period of a computer, some software modules may be removed and some may be added. The exact set of software modules in a load image is therefore difficult to manage especially when there are large numbers of optional software modules and when sub-systems are added or removed.
A common solution to this problem is to package all software sub-systems, including optional sub-systems, in a single load image and then enable only the optional sub-systems required using a key. This will permit storing a single image while allowing a large number of possible combinations through the use of the key. Using this solution, if a sub-system is dynamically added inito the load after the system is up and running, the load image can be updated by changing the key. However, although this solution works, a large section of the computer memory and/or hard disk is taken up by disabled software, which is clearly inefficient.
Another common solution to this problem is to build custom software loads where the customizing happens by having a specific subset of all possible optional software sub-systems build into the software load. Each of the custom software loads is then associated with a load identifier. These load identifiers are then stored in a load table in a memory device. A load table typically contains an entry for each possible permutation of the software load optional sub-systems. For example, a software product with four (4) optional sub-systems has 16 possible permutations and load table entries while a software product with six (6) optional sub-systems has 64 permutations and load table entries. The number of permutations is computed by the following equation: ##EQU1## where n is the number of optional sub-systems and ##EQU2## are the binomial coefficients. This number of permutations is potentially the number of load table entries needed for the optional sub-systems. As shown in equation 1, this number increases exponentially with the number of optional sub-systems yielding a large number of load identifiers that must be stored and managed. In addition, requesting the load image of a computer often involves a configuration management entity that coordinates the access to the software load table. In a typical interaction, a system management unit queries a computing node that is remote from the system management unit, requesting to know what software sub-systems are in its load, The computing node locates its load identifier and returns it to the system management unit. Following this, the system management unit sends a message to a configuration management unit that may also be also remote from the system management unit, requesting the load image associated to the Load. The system configuration management unit searches a load table for the entry with the corresponding Load and returns the load image to the system management unit. In addition to having large storage requirements for the software load table, this method does not allow to easily modify the software load image when adding software sub-systems. In effect, if a new sub-system is dynamically added into the load after the system is up and running the load image is no longer accurate. The implication is to have either an inaccurate load image or to search for the load identifier that suits the revised combination which is impractical even for a small number of optional modules.
Thus, there exists a need in the industry to provide an improved method and apparatus to permit computing devices to manage a software load image particularly well suited to software load with a large number of optional sub-systems and permitting the load image to be dynamically updated, particularly when sub-systems are being activated.